A file server is a computer that provides file service relating to the organization of information on storage devices, such as disks. The file server or filer may be embodied on a storage system including a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on the disks. Each “on-disk” file may be implemented as a set of disk blocks configured to store information, such as text, whereas the directory may be implemented as a specially-formatted file in which information about other files and directories are stored.
As used herein, the term storage operating system generally refers to the computer-executable code operable on a storage system that manages data access requests and may implement file system semantics in implementations involving filers. In this sense, the Data ONTAP™ storage operating system, available from Network Appliance, Inc. of Sunnyvale, Calif., which implements a Write Anywhere File Layout (WAFL™) file system, is an example of such a storage operating system implemented as a microkernel within an overall protocol stack and associated disk storage. The storage operating system can also be implemented as an application program operating over a general-purpose operating system, such as UNIX® or Windows NT®, or as a general-purpose operating system with configurable functionality.
A filer may be configured to operate according to a client/server model of information delivery to thereby allow many clients to access files stored on a server, e.g., the filer. In this model, the client may comprise an application, such as a file system protocol, executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the filer by issuing file system protocol messages, usually in the form of packets, to the filer over the network.
Broadly stated, clients and servers in a networked environment are assigned unique “addresses” within the network. Therefore, a packet of information communicated within a network can identify a source address and one or more destination addresses. The source address identifies the originator of a packet and the destination addresses identify intended recipients, e.g. file servers. Network addresses can be represented as alphanumeric computer names (such as URLs), numeric addresses, or both. Further, a client or server may be identified by more than one unique address within a single network or among a plurality of networks. Networks are usually associated with a naming service, e.g. the Network Information System (NIS) for UNIX-based networks and the Windows Internet Naming Service (WINS) for Windows®-based networks, that maps network addresses of different types (i.e., numeric and alphanumeric) for clients and servers. The process of converting one network address to an equivalent network address is referred to as name resolution. As used herein, name servers, domain servers and domain name servers will be used synonymously for those servers that perform name resolutions within a naming service.
The Domain Name Service (DNS) is the core naming service in the Internet. Almost all network communication between computers on the Internet use the Internet Protocol (IP) to specify the format of communicated packets or datagrams. The Internet Protocol uses numeric source and destination addresses known as IP addresses. Thus, the DNS typically maps alphanumeric computer names to numeric IP addresses so packets can be properly routed to their destination addresses. In intranets where filers are usually deployed, the DNS may be used to provide a naming service in conjunction with other naming services, such as NIS and WINS.
Usually communication to a filer is “client-initiated,” i.e., a client communication system initiates a request for some service and sends it to the filer. Subsequently, the filer responds to the client. However, the filer may authenticate a received request before responding. That is, the filer may match the source address in a received packet against an authentication database, which usually contains client system capability descriptions with clients identified by their alphanumeric names, to decide whether or not the client making the request has requisite permissions to be served. Therefore, the DNS (or NIS or WINS) on the filer side is not only used to resolve alphanumeric names to IP addresses when routing a datagram, but also to reverse-resolve IP addresses to symbolic alphanumeric names when authenticating client requests.
The DNS is implemented by code stored on the filer which, in this case, is functioning as a DNS client and corresponding code stored on a group of one or more DNS servers. As used herein, the code used to implement DNS on a client is called the DNS resolver code or resolver. In response to a request for “name to IP” or “IP to name” resolution, the resolver sends the request to a DNS server which may have the concerned mapping in its own database or may need to communicate with another DNS server to obtain the mapping. When the mapping is available, it is returned to the resolver code on the DNS client.
To expedite “name to IP” and “IP to name” resolutions, some DNS resolver implementations use a cache of DNS mappings stored locally or in an associated proxy cache server used to link the DNS client with a network. A proxy cache server (“proxy”) may be used to accelerate client access to the network (“forward proxy”) or to accelerate network access to the DNS client (“reverse proxy”). When resolving a name or an IP address, the resolver first attempts to resolve a request using mappings in its DNS cache. Cache entries are typically tagged with a validity time and outdated mappings are periodically deleted in accordance with a conventional aging algorithm.
DNS domain names are usually hierarchical and, consequently, DNS servers are often organized hierarchically. For example, a typical DNS name is:                www.eng.sunnyvale.netapp.comHere, “www” is the machine name. A first DNS server may be configured with all names that end in engsunnyvale.netapp.com (i.e., all machines of a NetApp engineering organization based in Sunnyvale). This server may not be configured with names in other domains such as marketing.sunnyvale.netapp.com which are stored in a second DNS server. A third DNS server may be configured with all subdomain servers in sunnyvale.netapp.com and can forward requests between the engineering and marketing Sunnyvale DNS servers. Furthermore, the sunnyvale.netapp.com DNS server may not be configured with addresses in the boston.netapp.com domain. Those mappings are provided by yet another DNS server such that a netapp.com DNS server can forward requests between the Sunnyvale and Boston NetApp servers. Finally, names outside NetApp may be resolved by “top-level” (root) DNS servers.        
In general, each DNS client stores its own DNS configuration for use by its resolver. A DNS configuration typically comprises an ordered list of IP addresses for “known” DNS servers, an ordered list of alphanumeric suffixes to be appended to non fully-qualified names and the domain in which the DNS client resides. The list of known servers in the DNS configuration indicates the order in which the resolver contacts DNS servers whose network addresses are known. The list of alphanumeric suffixes in the DNS configuration indicates the order in which the resolver appends suffixes to non fully-qualified names. As used herein, a fully-qualified DNS name ends with a “dot” and does not require additional suffixes in order to be resolved, where a suffix is expressly understood to be a trailing portion of a network address. For example, www.netapp.com. is a fully-qualified name, as indicated by its trailing dot, and a resolver would contact one or more DNS servers to resolve the name exactly as it is written. However, eng.netapp is a non fully-qualified name, and one or more additional suffixes would have to be appended by a resolver attempting to resolve its intended domain name.
Illustratively, the following DNS configuration could be stored in a DNS client, such as a filer, located in the eng.netapp.com domain:                domain eng.netapp.com        search eng.netapp.com, lab.netapp.com, netapp.com        nameserver 10.1.1.4        nameserver 10.1.2.6        nameserver 128.42.1.30In this example, if the resolver is asked to resolve a fully-qualified domain name such as foo.netapp.com. (notice the “.” at the end of the name), it first contacts the DNS server at 10.1.1.4 for the IP address of foo.netapp.com. If no response is received from 10.1.1.4, the resolver eventually “timeouts” and sends a request to the second DNS server at 10.1.2.6 to resolve the name foo.netapp.com. If this server does not respond, the resolver eventually moves on to the third DNS server 128.42.1.30. Reverse resolutions from IP addresses to names are handled in a similar fashion.        
In a situation where the resolver is asked to resolve a non-fully qualified name, such as foo or foo.eng, it sequentially appends the suffixes listed in its DNS configuration and tries to resolve the resulting names until one succeeds. For example, if foo.eng is the non fully-qualified name the resolver attempts to resolve, the resolver tries resolving foo.eng.eng.netapp.com, foo.eng.lab.netapp.com and foo.eng.netapp.com, in that order, until a resolution succeeds.
In summary, DNS clients comprise resolver code used to query one or more DNS servers when mapping an alphanumeric domain name to an IP address or vice versa. In some cases, the DNS client may be a filer seeking to authenticate a received data access request or a filer seeking to route data packets to other nodes in a network. Conventionally, the resolver code on a DNS client utilizes a configuration file to systematically resolve a “name to IP” or an “IP to name” request. For fully-qualified name resolution, the DNS configuration file typically includes an ordered list of DNS server addresses to contact. For non fully-qualified name resolution, the configuration file typically includes an ordered list of “trailing” suffixes that can be sequentially appended to the ends of non fully-qualified names being resolved.
The conventional DNS resolver implementation described suffers a number of problems when one or more DNS servers become inaccessible or “dead” to DNS clients. As used herein, a server is dead when it is inaccessible to clients attempting to access its services. A single domain name server could become inaccessible to DNS clients for any number of reasons, e.g., a system crash, a power outage, maintenance outage, etc. Worse yet, multiple servers could become inaccessible, e.g., if there is an outage in a poorly configured network. A conventional resolver typically does not record which servers are “alive” and which are “dead;” therefore, a typical DNS client will continue to contact dead servers even after those servers were previously identified as non-responsive. For instance, a conventional DNS resolver code will attempt to contact servers in the order they are listed in its DNS configuration even when it is known one or more of the servers listed are dead. The DNS servers are contacted in order, always starting with the first server in its DNS configuration, with each server given a predetermined waiting time to respond.
Furthermore, the sequential manner in which a conventional resolver attempts to contact servers in its DNS configuration can be unnecessarily time consuming even when no servers are dead. Sometimes, the DNS is designed so each DNS server can resolve only a sub-group of all possible network addresses. In such situations, the conventional resolver may require a failure from one or more servers listed earlier in its DNS configuration order before it contacts a server capable of performing a desired name resolution.
Disadvantageously, the conventional resolver implementation also does not record unresolvable or “bad” network addresses. As used herein, a network address, e.g. IP address or alphanumeric domain name, is bad when it cannot be resolved by a DNS client or server. Thus, a conventional DNS resolver continues attempting to resolve addresses that previously could not be resolved, thereby consuming time and resources that could be used for other name resolutions.
Additionally, the conventional resolver implementation suffers the disadvantage of not being able to identify fully-qualified names that do not end with a “dot.” In many cases when a fully-qualified DNS name is intended to be resolved, the trailing period used to indicate the name is fully-qualified is missing. Network administrators and users are often not aware of the trailing dot syntax, and DNS names intended to be fully-qualified are frequently specified without a trailing dot. Depending on its DNS configuration order, a conventional resolver may potentially have to test a full series of suffix resolutions before finally resolving the intended fully-qualified name. Thus, a conventional resolver may needlessly append suffixes and increase the time required to perform an address resolution.
The aforementioned problems with the conventional resolver implementation become amplified when DNS clients, such as filers, require authentication of a large number of source addresses in a short period of time. File servers often rely on the DNS for authentication purposes, and authentication in many file system protocols (e.g., NFS and CIFS) occurs at a session establishment time. Therefore, when an abnormal network event necessitates the establishment of a large number of new sessions in a short time period, e.g., due to power outages, failovers to backup servers, etc., the numerous resulting authentications may be delayed by the above-noted problems with the conventional resolver architecture. After such abnormal network events, DNS clients often have to rebuild their authentication databases by contacting an appropriate server. Thus, inefficiencies in conventional resolver techniques may “storm” DNS servers with requests at times when the servers are most likely to be unreachable or overwhelmed, e.g., processing requests to rebuild clients' authentication databases.
Previous methods have decreased the latency of resolving network addresses using a conventional DNS resolver. Traditionally, large amounts of DNS cache are used to minimize a resolver's reliance on external DNS servers and allow for quick name resolutions. Other methods rely on designing redundancy into a network of DNS servers so the failure of a small number of servers does not cause excessive delays for individual DNS resolvers. However, the previous methods do not alleviate latencies due to the large timeout values and sequential nature inherent to the conventional resolver algorithm previously described, nor do they do anything about quick resolution of improperly specified fully-qualified DNS names.